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[57] ABSTRACT 

In communication devices for conducting secure com- 
munications over insecure channels, means for detect- 
ing active attacks on voice or video communication is 
provided. These means enhance security of exchange of 
certificates, netkeys, and the like for use in securing 
subsequent voice, video, data, or facsimile communica- 
tions. 
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SECURE COMMUNICATION METHOD AND 
APPARATUS 

BACKGROUND OF THE INVENTION 5 

1. Field of the Invention 

This invention relates to communications, and partic- 
ularly to secure communications conducted over inse- 
cure channels using public-key methods* \q 

2. Description of the Related Art 

Communications in many media (voice, video, fac- 
simile, data, etc.) take place over many kinds of chan- 
nels (wire, radio, fiber optics, etc.)* Radio communica- 
tions may easily be intercepted, and wire and fiber optic 15 
communications may be intercepted by one with the 
requisite knowledge and equipment. 

When sensitive or proprietary information is to be 
communicated, means are sought to ensure that only 
authorized parties are permitted to receive (and in some 20 
cases, to send) such information. Many solutions in- 
volve "scrambling" or "encrypting" the information in 
ways that only an authorized receiving entity should be 
able to restructure. 

In modern cryptology it is usual for each party to a 25 
conversation or transmission to employ a security de- 
vice comprising digital electronic computation means 
to operate on digital data (voice or video signals having 
first been digitized) with sophisticated mathematical 3Q 
algorithms. Typical methods involve the use of "cryp- 
tovariables" or <( keys" known only to authorized send- 
ers and authorized receivers. A sender encrypts plain- 
text messages into ciphertext messages using a key, and 
the receiver decrypts the ciphertext using that key; 35 
interceptors, presumably not knowing the key, are un- 
able to recover the plaintext. 

Since the sender and receiver may be at considerable 
physical remove, logistical problems arise in propagat- 
ing the keys between them; secure channels must be 40 
found for the purpose, such as couriers; such secure 
channels tend to be slow and expensive. 

To alleviate these problems, methods known as "pub- 
lic key" methods have been devised wherein two enti- 
ties may determine a common cryptovariable upon 45 
initiation of their communication by exchanging infor- 
mation based on secret parameters known only to each 
of them, and then performing computations involving 
those secret parameters- The information they exchange 
is known as "public keys", and is subject to intercep- 50 
tion; an interceptor, presumably without access to the 
aforementioned secret parameters, is unable to deter- 
mine the cryptovariable and thus cannot decrypt the 
ensuing ciphertext. 55 

The prior-art public key methods are, however, sub- 
ject to a "man-in-the-middle attack" by a "spoofer". A 
spoofer may intercept a call from the calling party, and 
place a separate call to the intended called party, con- 
catenating the two calls with himself "in the middle"; gg 
using the aforementioned public key methods, he estab- 
lishes encrypted communication with both of them 
(with an extremely high probability of using different 
cryptovariables with each); he recovers the plaintext 
from one according to the appropriate cryptovariable, 65 
and re-encrypts it and passes it on to the other accord- 
ing to the appropriate cryptovariable, having full access 
to all plaintext. 



SUMMARY OF THE INVENTION 

The present invention provides, in a manner infeasi- 
ble to spoof in voice or video communication, verifica- 
tion between the calling party and the rightful called 
party that they have computed the same cryptovariable. 
Should such verification fail the parties conclude that 
they are under man-in-the-middle attack and refrain 
from transmitting sensitive information. 

Collaterally to computing their cryptovariables, the 
parties compute and display an "antispoof variable" 
which is small enough as to be easily read by each party 
to the other, yet large enough as to render it unlikely 
that each party and the spoofer will compute the same 
antispoof variable. Each party reports the antispoof 
variable to the other. In voice or video communication 
it is infeasible for a spoofer to spoof these reports with- 
out being detected. 

It is thus an object of the present invention to provide 
improved public-key secure communications. 

It is a particular object of the present invention to 
provide public-key secure communications resistant to 
man-in-the-middle attack. 

The novel features of construction and operation of 
the invention will be more clearly apparent during the 
course of the following description, reference being had 
to the accompanying drawings wherein has been illus- 
trated a preferred form of the device of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 schematically depicts a public-key communi- 
cation system of the prior art 

FIG. 2 schematically depicts a public-key communi- 
cation system of the prior art under man-in-the-middle 
attack. 

FIG. 3 schematically depicts a public-key communi- 
cation system according to the present invention. 

FIG. 4 is a schematic depiction of a public-key com- 
munication system according to the present invention 
and using netkeys, 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

One finds in common use public-key cryptographic 
systems based on the well-known Diftle-Hellman algo- 
rithm, set forth in U.S. Pat, No. 4,200,770, issued Apr. 
29, 1980 to Hellman et al. 

FIG. 1 depicts a secure communication system of the 
prior art employing the Diffie-Hellman algorithm. A 
calling party places a voice telephone call to called 
party over insecure channel 3. The calling party has a 
security device 1 comprising digital electronic compu- 
tation means, namely a random number generator 101, a 
cryptovariable generator 102, and a cryptographic de- 
vice 103; the called party has a similar device 2. In order 
to attain mnemonic clarity in the ensuing discussion, 
calling party 1 will be referred to as "Alice" and called 
party 2 as "Bob", which will be correlated with sub- 
scripts "A" associated with Alice and subscripts "B" 
associated with Bob. 

Alice and Bob are presumed to have telephone instru- 
ments (not shown) that generate digital representations 
of their voices, designated as the plaintext P. At the 
initiation of the call, Plaintext P is passed directly (i.e. 
without encryption) through cryptographic devices 103 
and 203. Alice's random number generator 101 pro- 
vides: 
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p, a prime number of the form 2q+ 1 (where q is a where fi is a mapping of binary vectors of length N to 

prime number) and having a binary vector length N. (N binary vectors of length K, where K is less than N. 

is > =512 and is typically 1024) Typical values for K are 56 through 80. 

x, a number in the integers mod p, called the base Cryptographic devices 103 and 203 are now acti- 

vector 5 vated, and under control of cryptovariable cv they 

ta, a random number in the integers mod q; the pres- encrypt plaintext P into ciphertext C for transmission 

ent embodiment uses a number of at least 160 bits. on insecure channel 3, and decrypt ciphertext C re- 

Cryptovariable generator 102 computes ceived from channel 3 to plaintext P. Alice and Bob 

may thus carry on what appears to them to be an ordi- 

Y^=x r >* mod p 10 nary telephone conversation, while eavesdroppers on 

channel 3 cannot determine the plaintext, 

and sends p, x, and YA over insecure channel 3 to Bob's However, the prior-art method just discussed is vul- 

cryptovariable generator- 202 (Alternatively, p and x nerable to a man-in- the-middle attack, as depicted in 

may have been previously agreed upon, in which case FIG. 2. Alice 1 attempts to place a call to Bob 2 over 

only Ya is transmitted.) It is important to note that these 15 channel 3; a spoofer, Sam 4, intercepts Alice's call and 

values are transmitted "in the clear"— Le., encryption immediately places a call to Bob over insecure channel 

has not yet begun. Any eavesdropper on the channel 3 5 - Sam is equipped with security devices analogous to 

could have access to them, but could not detemine t A or Alice's and Bob's. Sam concatenates his cryptographic 

t b from them since the functions for computing Y A and devices 403-1 and 403-2 by means of link 404 so that 

Y B are one-way functions; i.e., it is mathematically in- 20 Mice and Bob Perceive that they are in normal commu- 

feasible to determine their factors or roots. (See the mcatIon other *"? Perceive no indication that 

aforementioned Hellman patent at column 5, lines 1-41) a s P 00 / er has f tercepted their call. 

Upon receipt of those values Bob's random number As ***xsed m connection with FIG. 1, Alice sends 

generator 102 provides r& a random number in the „ £ x \ md Ya + ov * t . ^ umd 3 > f d they are received by 

integers mod « the present embodiment uses a number 25 f^w™ f% ^ yT 

of at least i« bits. Cryptovariable generator 202 com- JS^XS^ #^n£££ 

pu es batim passings-on of p, x, and over link 405 as re- 

Yax^mod p ceived from Alice, or they may be arbitrary coinages, 

and sends Y, over insecure channel 3 to Alice's oryp- 30 particularly, «r*y be assigned a trivial value (per- 

tovariable generator 102. ha P* 1 « ~ X ) b J Sam m ho P e * a ' UleI b y exanun f- 

Alice now has Bob's Y B and Bob has Alice's Y^. bon ° f . ^ f 1 *™ ^ ^ I CI ™' 0Vanab1 ' 
a v i • v j v e *.•••!•*/ 1 cv derived from that value (which Bob will have used 
After checlong p and Y ? for nontnv.al.ty (a spooler M y fFIG 1} he ^ be ^ tQ „ crack „ ^ secrct 

may have prov.ded a tnval value as wdl be discussed 35 eter from ^^^^g ^ dphert at C . 

further below) both now compute the Diffie-Hellman Sam ^ Tet[irn \ SA ^ Ueu of Yj? 

vanaoie. 0 j pjQ j j t ^ Q f nQ conse q uence whether Sam cora- 

Cryptovanable generator 102 computes putcs YsA from paadx feceived from Mi(x md a ^ 

binary number from his random number generator 
40 401-1, or whether he coins it arbitrarily, since Sam will 
not be originating any portion of the text passed in the 
*= x*/^ mod p communication between Alice and Bob and therefore 

= xr ArB mo&p has no need to protect anything. Sam may choose to 

make Ysa a trivial value, again in the hope of cracking 
while cryptovariable generator 202 computes 45 Alice's secret parameter t A from later inspection of the 

ciphertext encrypted with a cryptovariable computed 
using that trivial value of Ysa- 
dh B - Y A x r B mod p Alice and Sam both compute the same cryptovariable 

xTAyrs d CVsA based on Alice's Ya and Sam's bogus Ysa- When 

~ mod p 5Q ^jfog initiates encryption in her cryptographic device 

«= x^^modp 103 under control of that cryptovariable, she will be- 

lieve that only Bob can decrypt the ciphertext C A when 
It is thus seen that dh^32 dhj, or that Alice and Bob actually only Sam can. 

have both computed the same Diffie-Hellman variable. Bob and Sam both compute the same cryptovariable 
Yet an eavesdropper on the insecure channel 3 could 55 cvsb based on Bob's Yb and Sam's bogus Ysa. When 
not compute the Diffie-Hellman variable because of his Bob initiates encryption in his cryptographic device 203 
lack of access to xa or tb and the aforementioned infeasi- under control of that cryptovariable, he will believe 
bility of determining them from Y A or Yj. that only Alice can decrypt the ciphertext when 

The Diffie Hellman variable will henceforth be re- actually only Sam can. 
ferred to as dh. It is somewhat impractical to use dh 60 The plaintext of the dialogue between Alice and Bob 
directly as the cryptovariable cv, since dh is a very appears on link 404; Sam decrypts ciphertext Ca from 
large number (typically 5 12 to 1024 bits as noted above) Alice into plaintext P, and re-encrypts it into ciphertext 
and as such may tend to slow down the repetitive opera- and forwards it to Bob; Sam decrypts ciphertext Cb 

tions of encryption and decryption. Thus, cryptovaria- from Bob into plaintext P, and re-encrypts it into ci- 
ble generators 102 and 202 will form 65 phertext C A and forwards it to Alice. Sam has full ac- 

cess to the plaintext P on link 404, while Alice and Bob 
cv«f|(dh) perceive no indication that anything is amiss with the 

conversation they believe to be secret. 



dhA - Ybx? a mod p 



11/12/2003, EAST Version: 1.4.1 



5,450,- 

5 

Method 1: Anti-spoof variables 

FIG. 3 depicts a secure communication system ac- 
cording to the present invention. The two parties to an 
intended secure communication have security devices 
6, 7 according to the present invention. Security device 5 
6, for example, is equipped with display 104 which, in a 
present embodiment, can display four hexadecimal dig- 
its. 

The parties exchange public key information p, x f Ya, 
and Yb and compute dh as in the prior art. As in the io 
prior art, they compute the cryptovariable cv 

cv=f,(dh). 

According to the present invention, they also compute 15 
the antispoof variable asv 

asv=f2(dh) 

where f2 is a mapping from N-bit vectors to 4-digit hex 
vectors. Each party's antispoof variable asv is then 
displayed on displays 104 and 204 respectively. Absent 
an attack the two displays should be identical, but if an 
attack is in progress they will be different since the 
parties compute different values of dh. The parties re- 
port the displayed asv's to each other, and do not pro- 25 
ceed with secure communication unless their asv's com- 
pare. 

If Alice and Bob's call is under man-in-the-middle 
attack by spoofer Sam, two factors operate to preclude 
Sam from spoofing the asv comparison: 30 

1. Even if Sam's security devices are according to the 
present invention, they will not compute the same asv 
for the channel between Alice and Sam as for the chan- 
nel between Sam and Bob. (As discussed above, there is 

a very high probability that the the values of dh will be 35 
different for the two channels; therefore, asv=f2(dh) 
will also have different values for the two channels.) 

2. Although Sam, having full access to Alice and 
Bob's dialogue, can know when Alice and Bob are 
reporting their asv's, in a voice call it is virtually impos- 40 
sible for Sam to report his asv to Bob in such a manner 
that Bob is not alerted that anyone other than Alice is 
speaking to him, or for Sam to report his asv to Alice in 
like manner. Alice and Bob will thus know from the 
non-agreement of the asv's they report to each other 4 $ 
that their call is under man-in-the-middle attack by a 
spoofer, and will terminate their call without attempt- 
ing to pass any sensitive information. 

If Alice and Bob split their random-component mes- 
sages into two approximately equal halves, and fully SO 
transmit the first halves before transmitting the second 
halves, a spoofer will be precluded from mounting a 
birthday attack to discover their secret parameters. 
Method 2: Netkeys 

The asv confirmation depends on voice communica- 55 
tion for the two parties to make positive identification 
of one another. Another scheme for defeating a spoofer 
involves a shared secret known to the two parties and 
not accessible to the spoofer. Referring to FIG. 4, the 
parties each have security devices such as device 8, 60 
whick includes a netkey store 105 in which are stored 
secret netkeys nk indexed by netkey indices nid. Sup- 
pose that Alice and Bob want to make a secure fax call, 
and they find the Diffie-Heilman key exchange conve- 
nient. Concomittantly with the Diffie-Heilman ex- 65 
change, they determine whether they have a netkey in 
common; this may be accomplished by exchanging lists 
of nid's, or alternatively Alice may have used the serial 



6 

number of Bob's encryptor (automatically transmitted 
after initiation of the call) as the hid, and vice-versa for 
Bob. If they do have a common netkey, the common 
netkey is here designated nko Then active attacks by a 
spoofer can be defeated if Alice and Bob compute the 
cryptovariable as cv=f3(dh,nkc). 

In this case, the function f3 can be fairly simple (such 
as a projection on dh, followed by a mod-2 vector sum 
with nk). However, often it is advisable for this function 
to be a one-way hash value. This is only really necessary 
if dh were to be re-used, a situation that can be helpful 
in some protocols. 

Suppose a community of secure terminal users (for 
voice, video, fax, or data) is broken down into indepen- 
dent "subnetworks" and each subnetwork is defined by 
a netkey, nk. Each netkey has a unique index value nid. 
Then when Alice calls Bob they check as described 
above to see if they have a common value. If so, then 
they can proceed with a Diffie-Heilman exchange, and 
use the common netkey as above. Alice and Bob can 
then be assured that they are each talking to someone 
who knows the netkey value, and is therefore "on the 
net." The cryptovariable, cv, is still unique to the ses- 
sion however, so that if someone should subsequently 
compromise the netkey, all previous traffic is still pro- 
tected, and all future traffic is subject only to active 
attacks using the compromised netkey. Passive attacks 
will be unsuccessful. This approach will work well for 
all kinds of traffic (voice, data, video, FAX, etc.). 
Method 2A: Using anti-spoof variables to secure the 
establishment of a common netkey: 

There remains the matter of getting the actual com- 
mon netkey to both Bob and Alice; transmitting it in the 
clear or over a possibly compromised secure channel 
should not be attempted; aforementioned alternatives, 
such as a courier service, are slow and expensive. The 
aforementioned asv verification can be used to establish 
a netkey in a manner not vulnerable to man-in-the-mid- 
dle-attack, so that the netkey will not be compromised. 
Suppose that Alice and Bob have just decided to do 
business together and do not have a common netkey, 
but want to be able to send faxes securely to one another 
with assurance as to the source and destination of the 
fax plaintext. In order to establish a common netkey, 
Alice initiates a call to Bob using her security device 8. 
Her cryptovariable generator 102 determines that there 
is no common netkey between Alice and Bob, so it 
proceeds with a key exchange complete with computa- 
tion and display of the asv values. Alice and Bob then 
speak to one another and verify the asv values; if the asv 
values agree, the cv value is stored as a netkey nk in- 
stead of as a cryptovariable. The fax call, and subse- 
quent fax calls, can proceed using the netkey-based 
protocol. In Alice's terminal the netkey thus established 
can be stored and associated with a nid such as either 
Bob's phone number, or more properly with the serial 
number of Bob's FAX encryptor (which gets transmit- 
ted at the beginning of a FAX call, as noted above), and 
vice-versa for Bob. Alice and Bob never have to pre- 
arrange, or attend, another fax call. 
Method 3: Certificates: 

The above methods are fairly simple, can be adminis- 
tered with ininimal overhead, and they provide closely 
held control. These methods are ideal for users who 
know one another, which is usually the case in commer- 
cial secure voice, video, and fax communications, but 
not always. In military communications, security will 
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be necessary, but it is much more likely that the people Suppose that Alice wants to send a secure email mes- 

at the ends of a channel have never met or spoken to sage to Bob, Dan, and Carol. She composes the mes- 

one another. The commercial world appears to be sage, m, generates a random message cryptovariable 

evolving toward operations where secure and authenti- cv m , and uses it to encrypt the message. We presume 

cated communications need to proceed among parties 5 that the message is very long, with lots of attachments, 

who may never have met, and who communicate en- so that it is unreasonable for Alice to encrypt the mes- 

tirely over data links using store and forward networks. sage differently for each recipient. A typical network 

In fact the communicating parties may not be people, communication system might allow her to send one 

but rather computerized authorizing agents that follow message to the network, with instructions to broadcast 

some fixed set credit approval mechanism that refers to 10 it to the three named recipients. So, Alice sends the 

bank account records and spending patterns. As a step same encrypted message to Bob, Carol, and Dan, to- 

along the way to key management that can support such gether with a plaintext routing header, used by the mail 

processes, reliance may be placed on a third party who network, and with a security header that includes the 

certifies the identity of a person, role, or entity, and who means for each of the three to decrypt the message, 

binds that identity to a cryptographic parameter that 15 The security header includes a common part and an 

can be used for several security functions, including but entry for each recipient. Assume that Alice and Bob 

not limited to establishment of authenticated secure have a common netkey nj, and that Alice and Carol and 

channels. Dan share a common netkey n2- For the common part 

Suppose that Alice belongs to a community that of the security header, Alice generates a random num- 

agrees on the use of Diffie-Hellman parameters, p and x 20 ber S m , and includes that in the clear. The entire secu- 

as above. Also, suppose that Alice (and likewise every- rity header will be: 
one else in the community) generates a random number 

TA t and a public random component ic—x rA mod p. s " 
Next Alice submits her ID information together with rc 

to a certificate authority used by everyone in the com- 25 Bob: h * ni * s '«)® cv « 
munity. The certificate authority then creates a message 
digest from rc and ID, and signs the digest using the 

DSAjthe NISTDigital Signature Standard), producing Here> the hc) ^ ^ SRS ^ ^ ^ ^ 

a certificate m the form of a vector ^ Secure Rash Standard) applied t0 the concatena . 

c A =(ro, rc, sign(iD,rc». tion of its arguroente, and then projected to the same 

number cf bits as the message cryptovariable. The sym- 

Note that Alice does not reveal the random number r A , bo L® denotes I* 13 ? vector sum . 
which she keeps secret Thus the amount of trust she ™* J* 38 ? 11 tha * the jness^ge cv ? not encrypted di- 
must put in the certificate authority is somewhat lim- 35 *«&Y ^ the netkey for each recipient is that when 
ited. Actually, even though the certificate authority there are multiple recipients it would be possible for 
(CA) never gets access to the secret parts of public key D ^'J r exam P le > to recover the secret netkey for Bob 
pairs, the user community must put a lot of trust in the andAlice. 

CA This approach, in comparison to others, is fairly sim- 

If everyone in the community gets a similar certifi- 40 fa Xft squires only a small overhead in the message 
cate, we have implicitly created two-point netkeys that For each recipient, we only need send an addi- 

can be used to authenticate both sides of a communica- tlonal 14 h f x characters, if we use DES to encrypt the 
tion channel. This is because for any two certificates, mf ?™&> Pi™ labeling overhead, 
corresponding to any two individuals or entities A, B, in UAhce have any pre-stored netkeys, but has 

the community, there may exist a unique netkey 45 access to a public directory of certificates, and she her- 

self has a certificate Ca* then Alice can proceed as 
n AB '*fi<* rArff )- above by constructing bilateral netkeys as in method 3 

above. She constructs a security header that looks like: 

This netkey is implicitly bound by the certificate au- 
thority to the identities given in the certificates for 50 Ca > Sm 
entities A and B. This netkey can be used for all bilateral rArB 
communications and agreements between the entities A 0 : 

"fr^ v • a * • A- ^ Carol: Mx"^©^ 

Under a key management method using this netkey, 

when Alice contacts Bob, the two exchange certificates 55 v Dan: h{x rA 'D s„oecv m 
Ca and Cj, verify the signatures, compute the bilateral 

netkey tiab, and then proceed to use Method 2, as to each individual entry of the security header, the first 
above. That is, they perform a Diffie-Hellman key ex- argument of h is the common netkey variable derived 
change forming a new Diffie-Hellman variable, dh for from certificates as in method three. This store and 
this call, and compute the cryptovariable 60 forward scheme is not as secure as the circuit-based key 
cv=f3(dh,n^). All of the benefits of method 2 accrue. exchanges described above. This is because if, say, 
The result is a simple protocol which will work well for Bob's secret key r A is compromised, then all messages 
all communications over permanent, switched, and sent to Bob can be read, including messages that may 
virtual circuits. However, the scheme does not support have been recorded by an intruder before the compro- 
connectionless network communications, nor broadcast 65 m i se occurred. This problem can be limited somewhat 
communications. using a protocol that's a bit more complicated and re- 
Method 4: Secure Store-and-Forward and Broadcast quires more support: 
communications: 
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Method 4B: Use of Temporary Keys: 

In key management schemes for email, the use of 
X.509 certificates administered in the context of an 
X.500 directory server is generally assumed. Therefore, 
if Alice wants to send a message to Bob, she can look up 5 
both his email address and his security certificate at the 
same source. If both Bob and Alice want to be a little bit 
more careful in protecting messages. Bob can make 
available to Alice a mechanism for temporary variables: 
Bob generates a new temporary variable pair tbjj x rfl .' 10 
weekly. Bob can either publicly post or send Alice the 
public value, together with an index value ts, and an 
expiration date for the pair. In either case, the public 
value may or may not be signed using Bob's digital 
signature (which itself is certified by the certificate I 5 
authority, and is not to be confused with the key ex- 
change certificate described above). This week's tempo- 
rary variable can be used by everyone in the community 
to send messages to Bob. When Alice does so, Bob's 
entry in the security header of Alice's message will look 20 
like this: 

Bob: t& h(xM^ ( 3i'B.frAjA)®cv m 



10 



tended to be embraced by the appended claims and not 
limited by the foregoing embodiment 
What is claimed is: 

1. In an apparatus for communicating securely over 
an insecure communication channel of the type provid- 
ing for a calling entity and a called entity, each having 
such apparatus, to establish a cryptovariable for encryp- 
tion and decryption, the apparatus comprising means 
for 

retrieving or generating a first secret parameter in 
each apparatus; 

exchanging variables over said insecure channel in- 
cluding one-way transformations of said first secret 
parameters; 

independently computing in each apparatus a cryp- 
tovariable from said exchanged variables and said 
first secret parameters; 
transmitting* from each apparatus over said insecure 
channel data encrypted according to said cryp- 
tovariable; and 
decrypting in each apparatus data received over said 
insecure channel according to said cryptovariable, 
an improvement characterized by 
means for independently computing in each appara- 
tus an antispoof variable from said exchanged vari- 
ables and said first secret parameters; and 
means in each apparatus for displaying said antispoof 
variables; 

whereby a user associated with said calling entity and a 



In this case, Alice needs to reciprocate and provide a 25 
temporary variable, and post the public part, or include 
it in the security header. Now Bob can destroy the 
secret part of the temporary variable anytime after the 
expiration date plus some reasonable grace period, and 

Alice can destroy her temporary variable used above 30 user associated with said called entity may conversa- 
tionally exchange said antispoof variables, may con- 
clude that a third entity is interposed between said 
called and calling entities if said antispoof variables do 
not agree, and may terminate the communication there- 
35 upon. 

2. In an apparatus for communicating securely over 
an insecure communication channel of the type having 
means for a calling entity and a called entity, each hav- 
ing such apparatus, to establish a cryptovariable fer 
Then the recipients can use the temporary variable that 40 and decr yption, the apparatus comprising 

Alice posted in the header in order to respond to the 



anytime. However, if the security header is: 

CAt tA> * r<4,t > expiration data 
Bob: tyx 1 *'*, x'Z&A* *^)©cv m 
Carol: t 0 h(x^« x^.^.^)©cv m 
Ted: t r , K* rArD , x r to Dr *t*)®Qv m 



message. 

It is not difficult to construct a security header format 
that allows a mixture of Methods 4 and 4B. Under the 
assumption that people will send messages with the best 
security they have available to them, and although a 
mixture of method 4 and 4B reduces the overall security 
to method 4 under the weak link theory, there does 
seem to be added security value above use of Method 4 
only. 

Also note that if the temporary keys are signed then 
there may be no need to use the netkey in addition to the 
temporary key in order to construct the cover variable 
for the message key. However, we assume here that the 
temporary variables will not always be signed. 
Combination of Methods: 

In the sequence of methods described above, they can 
all be used in a protocol that permits the strongest and 
most convenient means to be used in any given situa- 
tion. For example, suppose Alice and Bob want to set 
up a secure voice call, then Method 2 can be the default, 
but if no common netkey were available, then either 
method 1 can be used to establish a common netkey (as 
outlined in Method 2A), or method 3 can be used. 

One skilled in the art will appreciate that the inven- 
tion may be embodied in other specific forms without 
departing from the spirit thereof. The invention is in- 



means for 

retrieving or generating a first secret parameter in 

each apparatus; 
exchanging variables over said insecure channel in- 
45 eluding one-way transformations of said first secret 
parameters; 

independently computing in each apparatus a cryp- 
tovariable from at least said exchanged variables 
and said first secret parameters; 

50 transmitting from each apparatus over said insecure 
channel data encrypted according to said cryp- 
tovariable; and 
• decrypting in each apparatus data received over said 
insecure channel according to said cryptovariable, 

55 an improvement characterized by 

means in each apparatus for storing and retrieving 
second secret parameters and indices each uniquely 
associated with a particular one of said second 
secret parameters; means for each entity to ex- 

60 change with the other over said insecure channel 
lists of said indices; 
means in each apparatus for determining from the 
exchanged lists whether the called and calling enti- 
ties have an index in common; 

65 said means in each apparatus for computing said 
cryptovariable computes said cryptovariable from 
said, exchanged variables, said first secret parame- 
ter, and said particular one of said second secret 
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parameters associated with the index determined to 
be common to the called and calling entities. 

3. A method for a calling entity and a called entity to 
communicate securely over an insecure communication 
channel wherein: 

each entity retrieves or generates secret parameters; 

each entity computes a one-way transformation from 
cne or more of the secret parameters; 

the entities exhange variables including the one-way 
transformations; 

the entities independently compute, from their own 
secret parameters and from the variables ex- 
changed from the other entity, a cryptovariable; 

the entities independently compute, from their own 
secret parameters and from the variables ex- 
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12 



15 



changed from the other entity, an antispoof vari- 
able; 

users associated with the entities verify that the antis- 
poof variables agree; and 
the entities conduct transmission over the insecure 
channel of data encrypted according to the cryp- 
tovariable before transmission and decrypted ac- 
cording to the cryptovariable after reception if the 
antispoof variables agree; or 
the entities terminate the communication if the antis- 
poof variables do not agree, 
whereby secure communication is not attempted if a 
third entity is interposed between the calling entity and 
the called entity. 
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